Many packet-based networks employ cryptographic keys to authenticate the identity of the sender of each packet sent across a communications link between a source node (e.g. switch or router) and a destination node. The motivation for such schemes is usually a desire to protect against the injection of packets into the communications link by a hacker so as to fool the destination node that the injected packets came from a trusted source node.
In a typical scheme, a source node wishing to send encrypted or unencrypted data to a destination node first applies a hash function and a cryptographic key to the data to generate a signature. The data and the signature are both written to a packet and the packet is sent to the destination node. Upon receipt of the packet, the destination node applies the same hash function and cryptographic key to generate a local “authentication” signature. If the authentication signature matches the signature from the packet, the destination node treats the data as being authentic. The same approach is used for data sent in the opposite direction.
Packet-based networks which employ cryptographic keys and signatures are referred to as secure packet networks. Packet-based networks which do not employ cryptographic keys and signatures are referred to as non-secure packet networks.
Typically, cryptographic keys used in secure packet networks are periodically refreshed (i.e. changed). The refreshing of a cryptographic key may alternatively be referred to as re-keying or as the provisioning of a new key.
Keys may be refreshed manually or automatically. In manual key refreshing, a key distribution scheme is used to notify a human operator at each node in the secure packet network that the cryptographic key is due to be refreshed and to provide the new cryptographic key to be provisioned. In response, the operator at each node configures his or her node to use the provided key. In automatic key refreshing, the key refresh is triggered from one network location (e.g. at a Network Management Server or NMS) and is automatically propagated throughout the network. The present description pertains to manual key refreshing.
A number of manual key refreshing solutions are known. In a first known solution, when an operator provisions a new key at a given network node, the node immediately begins using the new key both for generating signatures for outgoing packets and for checking signatures of incoming packets. Disadvantageously, this solution may result in lost packets during key refresh. This is because the provisioning of a new key at a source node will result in a rejection of all of the packets from the source node at the destination node because the source is using the new key to generate outgoing signatures while the destination is still using the old key for authentication of incoming signatures (i.e. the signature in the packet and the locally generated authentication signature will no longer match). This rejection of packets will continue until the destination node is provisioned with the new key. Depending upon the nature of operative higher level communications protocols, a loss of service between the nodes may result.
Another known solution is described in the Open Shortest Path First (OSPF) 2 Request For Comments (RFC) 2328, in a section pertaining to cryptographic keys. RFC 2328 is presently posted at URL http://www.ietf.org/rfc/rfc2328.txt.
In overview, OSPF 2 addresses the problem of lost packets during key refresh by provisioning multiple keys with overlapping time windows during which each key is “live”. Each provisioned key in OSPF 2 is assigned four timestamps: (1) the time at which the current node is to start sending packets containing signatures generated from the new key; (2) the time at which the current node is to start receiving packets containing signatures generated from the new key; (3) the time at which the current node is to stop sending packets containing signatures generated from the new key; and (4) the time at which the current node is to stop receiving packets containing signatures generated from the key. The timestamps are configured such that only one key is ever active for generating signatures for outgoing packets, yet they allow incoming packets to be authenticated at a destination node by any one of a number of currently active keys. The destination node will first attempt to authenticate using the first active key. If authentication fails, the node will then attempt to authenticate using the second active key, and so on, until either the packet is authenticated or there are no more keys. By appropriately configuring the timestamps of successive keys, manual key refresh can be achieved without lost packets even when a source node has begun using a new key for outgoing packets while the corresponding destination node is still using an old key for outgoing packets.
A disadvantage of OSPF 2 is the processing overhead which may result when a destination node is required to generate multiple authentication signatures during authentication. Since authentication is done for every received packet, the amount of processing power consumed at a destination node by this multiple authentication signature generation can be significant. The amount of overhead involved in generating four timestamps per key and distributing the timestamp information to an operator at each node in a network prior to each key refresh may also be considerable.
The Resource Reservation Protocol (RSVP) cryptographic authentication protocol described in RFC 2747 (http://www.ietf.org/rfc/rfc2747.txt) provides another known manual re-keying solution. This solution is similar to the OSPF 2 approach but uses fewer timestamps per key. This solution may suffer from similar disadvantages as OSPF 2, although likely to a lesser degree.
An alternative manual cryptographic key refresh solution would be desirable.